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Abstract 

Direction  based  spatial  relationships  are  critical  in  many  domains  including  geographic  informa¬ 
tion  systems(GIS)  and  image  interpretation.  They  are  also  frequently  used  as  selection  conditions 
in  spatial  queries.  In  this  paper,  we  explore  processing  of  queries  based  on  object-orientation-based 
directional  relationships.  A  new  Open  Shape  based  strategy(OSS)  is  proposed.  OSS  converts  the 
processing  of  the  direction  predicates  to  the  processing  of  topological  operations  between  open  shapes 
and  closed  geometry  objects.  Since  OSS  models  the  direction  region  as  an  OpenShape,  it  does  not 
need  to  know  the  boundary  of  the  embedding  world,  and  also  eliminating  the  computation  related 
to  the  world  boundary.  We  perform  algebraic  analysis  as  well  as  experimental  evaluation  for  OSS. 

The  experimental  result  demonstrates  that  the  OSS  consistently  outperforms  classical  range  query 
strategy  both  in  I/O  and  CPU  cost. 

Keywords:  Direction,  Orientation,  Open  shape,  Topological  operations,  Spatial  query  processing, 
Range  query. 
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1  Introduction 


“Direction”  is  a  common  spatial  concept  frequently  used  as  a  selection  condition  in  spatial  databases[9,  1] 
or  for  similarity  accessing  in  image  databases[16].  Examples  of  direction  queries  used  in  army  battlefield 
visualization^]  are  “List  the  enemy  targets  to  the  north  of  Building  B”,“Is  there  anything  over  the 
ridge?”,  and  “Describe  all  tanks  to  the  left  of  Landmark  L”.  The  first  example  refers  to  an  absolute 
directional  relationship  (north)  with  respect  to  Building  B,  the  second  involves  a  viewer-orientation- 
based  directional  relationship,  i.e.  the  direction  is  based  on  the  orientation  of  the  viewer,  and  the  third 
example  uses  an  object-orientation-based  direction  as  its  selection  criteria. 

It  is  important  for  a  spatial  database  system  to  provide  a  mechanism  for  modeling  and  processing 
direction  queries.  Most  of  the  previous  work  [2,  22,  14]  on  direction  query  processing  has  focused  on 
processing  predicates  of  absolute  directions(e.g.  North,  East)  using  range  query  strategies.  However, 
object-orientation-based  direction  queries  and  predicates(e.g.  left)  depend  on  the  orientation  of  reference 
objects,  which  may  be  different  from  the  global  reference  system.  Because  of  this  characteristic,  the 
strategies  that  are  efficient  for  absolute  directions  may  be  inefficient  when  used  for  object-orientation- 
based  directions. 

In  this  paper,  we  focus  on  the  processing  of  spatial  queries  involving  object-orientation-based  direction 
predicates  in  selection  conditions.  Based  on  direction  object  model  proposed  in  our  recent  work  [20], 
we  define  a  new  abstract  data  type(ADT)  for  open  shapes  and  propose  a  new  Open  Shape  based 
strategy(OSS).  OSS  transforms  the  computation  of  the  direction  predicates  into  the  computation  of 
topological  operations  between  open  shapes  and  objects.  Algebraic  analysis  and  experimental  evaluation 
demonstrate  that  OSS  consistently  outperforms  classical  strategies  both  in  I/O  and  CPU  cost. 

1.1  Problem  Definition 

Absolute  direction  of  a  target  object  relative  to  a  reference  object  is  defined  by  their  locations  in  the 
embedding  space.  Usually,  the  absolute  direction  is  described  in  context  of  a  global  2-D  coordinate  system 
e.g.  (north  up,  east  right)  as  shown  in  figure  1.  Some  examples  of  absolute  directional  relationships 
are  North,  East,  and  NorthEast.  Figure  1(a)  shows  a  small  part  of  the  campus  map  of  University 
of  Minnesota  with  a  car  C.  A  query  involving  an  absolute  direction  predicate  is  “List  all  buildings 
north  of  C”.  The  dashed  shaded  rectangle  in  the  figure  shows  the  region  satisfying  the  query  selection 
condition  North.  This  shaded  rectangle  is  called  direction  region,  which  consists  exactly  of  all  the  points 
satisfying  the  direction  predicate.  The  query  identifies  “Northrop  Memorial  Auditorium”  as  the  only 
building  satisfying  the  query. 

Object-orientation-based  direction  of  a  target  object  is  described  with  respect  to  the  orientation  of  a 
reference  object.  The  orientation  of  the  target  object  is  not  relevant.  In  figure  2,  the  desk  is  an  oriented 
object,  but  the  flag  is  not.  The  flag  is  to  the  right  of  the  desk  based  on  the  orientation  of  the  desk.  In 
other  words,  imagine  the  reference  object  desk  were  a  person,  then  object-orientation-based  direction  is 
described  with  respect  to  the  person’s  orientation  and  location. 

In  Figure  1(a),  the  car  C  has  an  intrinsic  orientation  described  by  the  direction  front.  Consider  a 
query  based  on  the  orientation  of  C,  i.e.,  object-orientation-based  direction  query,  “List  all  the  buildings 
in  front  of  the  car  C” .  The  solid  shaded  region  shows  the  direction  region  for  “in  front  of  the  car  C” , 
and  hence,  the  buildings  in  front  of  the  car  include  “Tate  lab”,  “Morrill  Hall”,  and  “Architecture”. 
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(a)  Campus  map  of  University  of  Minnesota 


(b)  Approximate  buildings  by  MBRs 


Figure  1:  Absolute  direction  vs.  Object-orientation-based  direction 


Figure  2:  Object-orientation-based  direction:  The  flag  is  to  the  right  of  the  desk,  assuming  front  of  desk 
is  facing  out  of  the  paper 

It  is  common  to  approximate  2-D  regions  by  minimum  bounding  rectangles  (MBRs)  which  are  or¬ 
thogonal  with  respect  to  the  global  coordinate  system.  We  refer  to  this  type  of  MBR  as  MBRg.  Figure 
1(b)  replaces  all  the  buildings  in  Figure  1(a)  by  their  corresponding  MBRgs.  However,  for  a  reference 
object,  the  MBR  may  need  to  be  taken  based  on  the  orientation  of  the  object.  We  represent  this  type 
of  MBR  as  MBR0.  Figure  3  shows  examples  of  these  two  MBR  types  for  a  given  object.  The  dashed 
orthogonal  rectangle  is  the  MBR  according  to  the  global  coordinate  system,  and  the  solid  rectangle  is 
the  MBR  according  to  the  orientation  of  the  object. 

Collections  of  MBRgs  can  be  organized  by  a  R-tree  for  efficient  search.  Readers  not  familiar  with 
R-trees  may  refer  to  related  literature  [23,  10,  5].  In  the  rest  of  the  paper,  we  assume  data  objects 
are  approximated  by  MBRg  and  reference  objects  are  approximated  by  MBR0.  For  simplicity,  if  not 
explicitly  clarified,  MBR  represents  MBRg. 

In  this  paper,  we  intend  to  explore  processing  strategies  for  spatial  queries  which  involve  object- 
orientation-based  direction  predicates  as  selection  criteria.  The  problem  is  denoted  as  Object- 
Orientation-based  Direction  Queries(OODQ)  and  can  be  formally  defined  as  follows: 

Object-Orientation-based  Direction  Queries(OODQ)  problem: 

Given:  (a)  A  query  involving  an  object-orientation-based  direction  predicate  in  selection  conditions 
(b)  a  R-tree  index  of  the  dataset 
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MBRg 


Figure  3:  Different  MBRs  according  to  different  coordinate  systems 

Find:  All  objects  satisfying  the  selection  condition 
Objective:  Minimize  the  number  of  page  access. 

Constraint:  (a)  Objects  are  approximated  as  MBRg. 

(b)  There  is  only  one  R-tree  index  based  on  global  coordinate  system 

1.2  Related  work  and  our  contributions 

Direction  is  often  modeled  as  a  binary  relationship  between  objects  [3,  18,  6,  24,  1,  15,  7,  4,  19,  13]. 
Different  direction  predicate  sets  [14,  6,  11,  3]  have  been  proposed  using  binary  relationship  view  of 
directions.  Research  on  processing  direction-based  queries  has  explored  indexing  methods  and  processing 
strategies.  A  previous  study[22]  evaluated  different  indices  for  processing  absolute  direction  queries. 
Its  results  showed  that  spatial  index  (e.g.  R-tree)  is  efficient  for  retrieving  queries  with  constraints 
on  both  dimensions.  Range  query  strategy(RQS)  was  used  to  implement  queries  involving  absolute 
directions[2,  22,  14].  For  example,  consider  the  query  based  on  the  objects  in  Figure  4:  Find  all  objects 
that  are  exactly  east  of  object  B.  In  the  context  of  absolute  directions,  the  x-axis  and  y-axis  of  the 
coordinate  system  may  be  aligned  with  the  East  and  North  directions.  The  direction  queries  based  on 
absolute  directions(B’s  East)  can  be  viewed  as  a  special  case  of  range  query  as  shown  in  figure  4.  Here, 


North(y-axix) 


East(x-axis) 


Figure  4:  Processing  absolute  direction  query  using  range  query  strategy 

all  the  objects  whose  interiors  intersect  with  the  interior  of  the  shaded  direction  region  belong  to  the 
query  result.  Since  an  absolute  direction  is  based  on  the  global  reference  system,  its  direction  region  is 
a  rectangle  with  sides  parallel  to  the  axes  of  the  global  coordinate  system.  It  is  natural  and  efficient 
to  use  range  query  strategy[22],  which  is  specified  by  Algorithm  1  named  RQS.AD.  RQS_AD  finds  all 
object  MBRs  satisfying  a  given  direction  predicate  using  a  R-tree.  The  input  of  RQS.AD  is  a  set  of 
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data  objects  indexed  by  a  R-tree  and  a  direction  region  (dirRectangle).  This  algorithm  starts  from  the 
root  node  of  R-tree,  excludes  the  intermediate  nodes  whose  MBRs  do  not  intersect  with  dirRectangle , 
and  recursively  searches  the  children  of  the  remaining  intermediate  nodes.  A  refinement  using  the  exact 
geometry  of  these  objects  may  occur.  But  for  simplicity,  we  will  omit  that  in  the  rest  of  the  paper. 


Algorithm  1  RQS AD:  Processing  Absolute  Direction  Query  using  Range  Query  Strategy 

Input:  rtree  is  the  R-tree  index  for  the  dataset; 
dirRectangle  is  the  direction  region 

Output:  resultSet  contains  all  object  MBRs  whose  interiors  intersect  with  dirRectangle 


RQS_AD(R-tree  *rtree,  Rectangle  dirRectangle)  { 
currentNode  =  rtree; 

if  overlaps(currentNode.Mbr,  dirRectangle)  { 
if  (currentNode  is  a  leaf  node) 

Add  currentNode  to  resultSet; 

else 


} 


} 


for  each  childNode  €  child  node  of  currentNode 
RQS_AD(childNode,  dirRectangle); 


Let  us  now  consider  extension  of  RQS.AD  for  object-orientation-based  direction  queries.  If  the  ori¬ 
entation  of  the  reference  object  is  not  aligned  with  the  global  coordinate  system,  then  the  corresponding 
direction  region  will  not  have  sides  parallel  to  the  axes  of  the  global  coordinate  system.  One  way  to 
use  range  query  strategy  for  object-orientation-based  directional  relationship  is  first  to  calculate  MBRg 
of  the  direction  region,  and  then  use  this  MBR  as  the  range  query  constraint.  The  algorithm  RQS 
shows  the  steps  for  object-orientation-based  direction  query  processing.  Since  the  MBR  of  the  direction 
region  is  a  coarse  approximation  of  the  actual  direction  region,  the  intermediate  result  set  produced  by 
RQS -AD  may  contain  objects  whose  MBRs  do  not  intersect  with  the  interior  of  the  direction  region.  A 


Algorithm  2  RQS:  Processing  object-orientation-based  direction  query  using  range  query  strategy 

Input:  rtree  points  to  the  R-tree  of  data  objects; 

referenceObject  is  the  reference  object  with  intrinsic  orientation  ; 
dirPredicate  is  the  predicate  involved  in  the  selection  condition  of  the  query; 

Output:  resultSet  =  All  object  MBRs  which  satisfy  the  query 

RQS(R-tree  *rtree,  Geometry  referenceObject,  Predicate  dirPredicate)  { 

directionRegion  =  computeDirRegion(referenceObject,  dirPredicate); 
directionMBR  =  getMBR(directionRegion); 

intermediateResult  =  RQS_AD(rtree,  directionMBR);  /*  see  algorithm  1*/ 
resultSet  =  postFilter(intermediateResult); 

} 


post. Filter  step  is  needed  to  eliminate  false  hits. 

Figure  5  illustrates  the  query  processing  using  range  query  strategy  (RQS).  There  is  a  reference  object 
B  with  orientation  as  shown  in  figure  5.  The  query  to  be  processed  is  List  all  objects  which  are  exactly 
in  front  of  B.  The  shaded  region  is  the  direction  region,  and  the  dashed  rectangle  is  directionMBR 
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(b)  Range  Query 


(c)  Direction  region 


Figure  5:  Processing  object-orientation-based  query  using  range  query  strategy 

which  is  calculated  via  subroutine  getMBR.  By  applying  algorithm  RQS-AD,  we  obtain  all  the  objects 
whose  MBRs  intersect  with  the  interior  of  directionMBR.  The  object  selected  are  N21,  N23,  N33,  N42, 
N43,  N44  as  shown  in  Table  1.  A  post-filtering  step  is  needed  to  exclude  from  intermediateResult  those 
objects  whose  MBRs  do  not  intersect  with  the  interior  of  directionRegion.  The  data  MBRs  selected  are 
N31  and  N32.  Table  1  lists  the  trace  of  the  query  processing,  only  node  N1  is  excluded  in  the  first  level 


Steps 

MBRs  excluded 

MBRs  remain 

level  1 

N1 

N2,  N3,  N4 

level  2 

N41,  N22 

N21,  N23,  N31,  N32,  N33,  N42,  N43,  N44 

postFilter 

N21,  N23,  N33,  N42,  N43,  N44 

N31,  N32 

Table  1:  Trace  of  the  query  processing 


retrieval  of  R-tree,  although  node  N2  and  N4  are  not  satisfied  with  the  direction  predicate.  There  are 
eight  object  MBRs  to  be  checked  in  the  postFilter  step  and  only  two  of  them  satisfy  the  query. 

As  seen  from  the  above  example,  range  query  strategy  can  be  used  as  a  filter  step  to  process  object- 
orientation-based  direction  queries.  However,  in  many  instances  the  directionMBR  is  much  larger  than 
the  direction  region,  which  incurs  unnecessary  I/O  and  CPU  costs.  The  intermediate  result  contains 
a  large  number  of  false  hits.  A  postFilter  step  is  required  to  check  for  intersection  with  the  direction 
region,  leading  to  additional  CPU  overhead. 

In  this  paper,  we  propose  a  new  strategy,  namely,  Open  Shape  based  Strategy  (OSS),  for  processing 
object-orientation-based  direction  queries.  The  basic  idea  is  to  use  the  actual  direction  region  as  the  filter 
during  traversal  of  spatial  indices  to  exclude  potential  false  hits  as  early  as  possible.  This  is  accomplished 
by  modeling  direction  regions  as  a  new  ADT,  namely  OpenShape,  defined  in  terms  of  direction  objects 
and  operators.  Open  shapes  refer  to  the  geometries  whose  boundaries  are  partially  defined.  Open  shape 
objects  conceptually  extend  beyond  the  the  boundary  of  embedding  world.  Figure  5(c)  shows  the  open 
direction  region.  Since  OSS  models  the  direction  region  as  an  OpenShape,  it  does  not  need  to  know  the 
boundary  of  the  embedding  world,  eliminating  the  computation  related  to  the  world  boundary.  OSS 
converts  the  calculation  related  to  the  direction  predicates  into  the  computation  of  topological  operations 
between  OpenShapes  and  closed  geometric  objects.  OSS  filters  out  irrelevant  intermediate  nodes  during 
recursive  search  of  R-tree.  It  eliminates  the  postFilter  step  of  RQS  for  MBR  objects.  Algebraic  analysis 
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and  experiment  results  demonstrate  that  the  OSS  outperforms  RQS  (range  query  strategy)  both  in  terms 
of  I/O  cost  and  CPU  cost.  Relative  performance  of  OSS  in  comparison  to  RQS  is  affected  by  several 
parameters  including  the  orientation  and  size  of  the  reference  object,  the  overlap  degree  of  the  data  sets, 
and  the  type  of  direction  predicate.  On  average,  the  best  relative  performance  improvement  is  achieved 
when  angle  between  front  axis  and  x-axis  is  close  to  j  +  k  x  f(k  is  an  integer).  Relative  performance 
improves  with  the  decrease  in  the  size  of  the  reference  objects. 

1.3  Scope  and  Outline 

In  this  paper,  we  propose  a  new  strategy  to  process  object-orientation-based  direction  queries.  We  focus 
on  queries  that  involve  object-orientation-based  directional  relationships  between  simple  region  objects. 
We  approximate  the  region  objects  by  MBRgs.  A  set  of  object-orientation-based  direction  predicates 
between  region  objects  is  defined,  and  our  discussion  about  query  processing  is  based  on  the  predicates 
within  this  set.  We  assume  that  there  is  only  one  R-tree  index  with  fixed  orientation.  The  situation 
with  multiple  R-tree  indices  with  different  orientation  is  out  of  the  scope  of  this  paper. 

The  organization  of  this  paper  is  as  follows:  In  section  2,  we  define  a  set  of  direction  predicates  for 
region  objects.  In  section  3,  a  new  strategy  OSS  is  proposed  to  process  the  queries  involving  direction 
predicates.  A  new  ADT  for  modeling  direction  region  is  defined  in  section  3  as  well.  In  section  4,  an 
algebraic  analysis  for  OSS  is  performed.  The  experimental  evaluation  is  discussed  in  section  5.  The 
paper  ends  with  conclusions  and  recommendations  for  future  work. 

2  Object-Orientation-based  Direction  Predicates 

In  this  section,  we  will  give  a  brief  review  of  the  direction  model  and  define  an  example  set  of  direction 
predicates  between  region  objects.  More  details  on  direction  objects  are  available  in  [20]. 

2.1  Basic  Concepts:  Direction  and  Orientation 

Direction  is  defined  as  a  unit  vector,  i.e.,  a  vector  with  magnitude  equal  to  1.  Table  2  defines  the 
operations  on  directions  using  vector  algebra  operations. 


Operations 

Definition 

compose 

dl  +  d2= 

\dl-\-d2\ 

deviation 

— t  — t 

cos8  =  di  ©  d-2 

reverse 

(-1)  x  di 

isBetween1 

— t  — *  — t  — t  — t  — t 

d  is  between  d\  and  d-2  if  3ci  >  0,  C2  >0  s.t.  d  =  c\d\  +  cotfe 

Table  2:  Operations  on  Directions  di,dn 


Operations  on  directions  can  be  classified  into  three  categories.  The  first  category  contains  the 
operations  that  produce  new  directions:  compose  and  reverse  are  operations  in  this  category.  The 
compose  operation  is  actually  achieved  by  vector- addition,  and  the  resulting  vector  is  scaled  down  by 

lrThis  definition  works  well  as  long  as  vector  d\  is  not  parallel  to  vector  d 2.  The  parallel  case  can  be  handled  in  a  user 
defined  manner. 
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its  magnitude  to  be  a  unit  vector,  which  represents  the  new  direction.  The  reverse  operator  produces 
the  reverse  direction  vector.  The  second  category  of  operations  is  to  calculate  the  deviation  between 
two  directions.  Operator  deviation  calculates  the  cosine  of  the  angle  between  two  directions,  and  hence 
gives  the  deviation  of  one  direction  from  the  other.  A  pair  of  vectors  are  orthogonal  if  their  dot-product 
equals  zero,  i.e. ,  they  have  90°  deviation.  The  last  category  of  operations  test  the  relationships  among 
directions.  The  operator  isBetween  belongs  to  this  category.  In  figure  6,  d  is  between  d\  and  d-2',  however, 
d\  is  not  between  d  and  do. 


Figure  6:  direction  d  is  between  (dl,d2) 


Orientation  is  modeled  as  a  spatial  object  which  consists  of  a  point  of  origin  and  N  pair-wise  orthog¬ 
onal  directions,  where  N  is  the  dimension  of  the  embedding  space.  The  origin  point  and  the  N  directions 
form  a  Cartesian  Coordinate  System.  In  2D  space,  the  two  directions  may  be  labeled  as  the  right  and 
front  directions  of  the  orientation.  Formally,  we  can  define  orientation  and  its  operations  in  2D  space 
as  follows: 

Orientation  is  a  triple  0=  (OP,  right ,  front),  where  OP  is  a  point,  and  right,  front  are  two  orthogonal 
directions.  It  has  two  operations: 

•  translate(0,v)  =  (translate(OP,  v),  right,  front)', 

•  rotate{0 ,rotationMatrix)  =  (OP,rightn,  frontn), 
where  (rightn,  frontn)=  (right,  front)®  rotation  Matrix', 


An  example  of  the  rotation  Matrix  which  rotates  the  orientation  along  the  origin  point  for  an  angle 
6  is[17] : 

cos(6)  —sin(0) 

°p  sin(6)  cos(6 ) 

Table  3  gives  an  illustration  of  these  operations. 


Table  3:  Operations  on  orientation 
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ADTs  for  direction  and  orientation  objects  are  described  in  Appendix  A.  We  will  use  the  C++  dot 
notation  in  the  rest  of  the  paper  to  refer  to  the  attributes  and  operations  of  direction  and  orientation 
objects. 

2.2  Direction  Predicates  Between  Region  Objects 

After  reviewing  direction  and  orientation  objects  and  their  operators,  we  now  model  object-orientation- 
based  directions  between  region  objects.  We  begin  by  defining  an  example  set  of  direction  predicates. 
Table  4  gives  the  definition  of  our  predicates  in  terms  of  the  isBetween  operator.  Left  column  in 
Table  4  lists  the  object-orientation-based  direction  predicates  between  regions.  Right  column  provides 


Predicates 

Definitions 

SP)A,B ) 

3  point  P  G  A,  s.t.  P  €  interior(B) 

EF)A,  B) 

— t  — t  — t 

3  point  P  6  A,  s.t.  B)fP.isBetween(front,  right) A 

BrfP  .isBetween)  front,  right.reverse ()) 

EB)A,B ) 

— t  — *  — * 

3  point  P  G  A,  s.t.  Bn,P.isBetween{front.reverse(),  right) A 

Bri,P. isBetween) front. reverse)),  right,. reverse))) 

ER)A,  B ) 

3  point  P  G  A,  s.t.  BrfP AsBetween)f  ront, .reverse)), right)/\ 

Brf)P.  is  Between)  front,  right) 

EL)A,  B) 

3  point  P  G  A,  s.t.  B^P  ,isBetween)f  ront, right, .reverse))) A 

B^P ,isBetween)front,  right) 

RF)A,B ) 

3  point  P  G  A,  s.t.  Brf  P A s Between)  front,  right) 

RB)A,  B) 

3  point  P  G  A,  s.t.  Brt,P ,isBetween)f  ront,. reverse)) ,  right) 

LF(A,B ) 

3  point  P  G  A,  s.t.  Bi f  P ,isBetween)f ront, right.reverse))) 

LB)A,  B) 

— t  — t  — t 

3  point  P  G  A,  s.t.  Bit,P.  isBetween)  front,  reverse)),  right.reverse))) 

Table  4:  Direction  Predicates  for  MBR  Objects 


a  definition  for  the  corresponding  predicate  using  basic  concepts  from  section  2.1.  A  predicate  between 
target  region  A  and  reference  region  B  can  be  defined  in  terms  of  the  directional  relationship  between  a 
point  inside  A  and  the  four  corner  points  of  B.  It’s  easily  explained  via  Figure  7.  The  orientation  Ob 
of  the  reference  object  B  illustrated  in  figure  7(a)  contains  two  orthogonal  direction  objects  front  and 
right  representing  B’s  front  and  right  directions.  Figure  7(b)  illustrates  the  corresponding  direction 
regions  for  direction  predicates.  The  directions  left  and  behind  can  be  represented  as  right.reverse )) 
and  front.reverse))  by  using  the  reverse  operator  of  the  direction  object.  The  discussions  can  be 
extended  to  three  dimensions  by  adding  an  orthogonal  axis  above. 

The  predicate  set  defined  in  Table  4  consists  of  nine  predicates,  each  of  which  checks  whether  the 
target  object  A  is  overlapped  with  a  specific  direction  region  of  object  B  with  respect  to  B’s  orientation. 
EF)A,B ),  EB)A,B),  EL)A,B),  and  ER)A,B)  return  TRUE  if  and  only  if  object  A  is  overlapped 
with  the  EF,  EB,  ER,  and  EL  regions  of  B  respectively  as  shown  in  figure  7.  This  can  be  formally 
defined  using  isBetween  operator.  For  instance,  EF(A,  B )  is  TRUE  if  and  only  if  there  exists  a  point 
P  in  A,  such  that,  point  P  is  within  the  direction  region  of  EF.  In  other  words,  the  direction  BifP 
is  between  front  and  right  and  the  direction  BrfP  is  between  front  and  right.reverse))  as  listed  in 
Table  4.  Similarly,  the  predicates  RF)A,B),  LF)A,B ),  RB)A,B),  and  LB)A,B)  will  be  satisfied  if 


(a)  Reference  object 


(b)  Direction  regions 


(c)  EF(A,B)  iff  3  a  point  P  E  A, 
BifP.isBetween( front,  right) A 
Brf  P. is Between( front,  right. r ever seQ) 


Figure  7:  Direction  Regions  for  MBR  Objects,  B//,  B/&,  Brf  and  Bri •,  represent  B’s  left-front,  left-behind, 
right-front  and  right-behind  corners  respectively 


and  only  if  there  exists  any  point  Q  in  A  that  Q  is  in  the  corresponding  direction  region.  For  example, 
RF(A,B)  =  TRUE  iff  there  is  a  point  Q  satisfying  that  BrfQ  is  between  front  and  right. 

Lemma  1  Predicate  set  defined  in  Table  4  is  complete,  i.e.,  For  any  pair  of  simple  region  objects  A  and 
B  with  no  holes,  The  direction  of  target  object  A  with  respect  to  the  reference  B  can  be  represented  in 
terms  of  a  single  predicate  or  a  disjunction  of  several  predicates  in  the  predicate  set. 

Proof:  As  a  simple  convex  objects  without  holes,  the  target  region  object  A  must  contain  at  least  three 
points  that  do  not  form  a  line  segment.  It  is  impossible  that  all  the  points  are  located  on  the  boundary 
between  two  direction  regions.  In  other  words,  there  must  exist  at  least  one  point  located  in  one  of 
the  direction  region.  And  hence,  the  directional  relationship  can  be  represented  by  the  predicate  that 
corresponding  to  that  direction  region.  ■ 

3  Proposed  Approach  for  Object-Orientation-based  Direction 
Queries 

We  propose  an  open  shape  based  strategy(OSS)  using  the  actual  direction  regions  modeled  as  open 
shapes.  The  processing  of  the  direction  predicates  is  then  converted  to  the  processing  of  the  topological 
operations  between  target  object  and  the  corresponding  open  regions.  In  this  section,  we  will  first 
formalize  the  open  shape  based  strategy  and  then  describe  new  ADT  of  open  shapes  to  explain  the 
approach.  This  top-down  description  is  used  to  simplify  the  presentation. 

3.1  Proposed  Open  Shape  Based  Strateg^OSS) 

The  goal  of  the  open  shape  based  strategy  (OSS)  is  to  improve  filtering  efficiency  by  eliminating  false  hits 
at  the  earliest  opportunity  while  recursively  searching  R-tree.  OSS  uses  the  actual  direction  region  as 
the  filter  to  exclude  those  intermediate  nodes  that  do  not  satisfy  the  direction  predicate.  No  refinement 
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step  is  needed  if  objects  are  MBRs.  Algorithm  3  shows  the  steps  of  OSS.  First,  OSS  constructs  a  new 


Algorithm  3  OSS:  Processing  object-orientation-based  query  using  OpenShape-based  Strategy 

Input:  rtree  points  to  the  R-tree  of  data  objects; 

referenceObject  is  the  reference  object  with  intrinsic  orientation; 
dirPredicate  is  the  direction  predicate  involved  in  the  selection  condition  of  the  query; 
Output:  resultSet  contains  all  object  MBRs  which  satisfy  the  query 


OSS(R-tree  *rtree,  Geometry  referenceObject,  Predicate  dirPredicate)  { 

Object  *resultSet  =  0  ; 

OpenShape  dpRegion  =  ConstructOpenShape  (referenceObject,  dirPredicate); 
osQuery(rtree,  dpRegion,  resultSet);  //find  all  objects  interiorlntersect  dpRegion 

} 


osQuery( R-tree  *rtree,  OpenShape  dpRegion,  Object  *resultSet)  { 
R-tree  *currentl\lode  =  rtree; 

if  dpRegion. m<erior/n<er\secte(currentNode.Mbr)  { 
if  (currentNode  is  a  leaf  node) 

Add  currentNode  to  resultSet; 

else 


} 


} 


for  each  childNode  6  child  nodes  of  currentNode 
osQuery(childNode,  dpRegion,  resultSet); 


ADT  OpenShape  to  represent  the  actual  direction  region.  After  obtaining  dpRegion,  OSS  calls  the 
subroutine  osQuery  with  parameters  rtree  and  dpRegion  to  find  all  objects  whose  interiors  intersect 
with  the  interior  of  dpRegion.  The  subroutine  osQuery  recursively  checks  if  the  MBR  of  the  current 
node  intersects  with  dpRegion.  The  function  interior  Intersects  is  designed  as  a  member  function  of 
OpenShape,  and  returns  TRUE  if  and  only  if  the  interior  of  the  input  object  intersects  with  the  interior 
of  OpenShape.  Since  OSS  models  the  direction  region  as  an  OpenShape,  it  does  not  need  to  know  the 
boundary  of  the  embedding  world,  and  thus  eliminating  the  computation  related  to  the  world  boundary. 

Revisit  the  example  in  figure  5,  given  reference  object  B  and  its  orientation,  we  want  to  find  all  objects 
that  are  EF  of  B.  First  OSS  constructs  the  OpenShape(  dpRegion)  of  the  direction  region  represented  by 
shadow  in  figure  5.  After  dpRegion  is  created,  the  second  step  is  to  check  interior  Inter  sects  relationships 
for  the  entries  in  the  root  of  the  R-tree.  Only  N3  remains  after  retrieving  the  first  level  of  the  R-tree, 
and  N31  and  N32  are  in  resultSet.  Table  5  lists  the  steps  of  query  processing  using  OSS  strategy.  For 
MBR  objects,  no  refinement  step  needs  to  be  performed. 


Steps 

MBRs  excluded 

MBRs  remain 

level  1 

Nl,  N2,  N4 

N3 

level  2 

N33,  N34 

N31,  N32 

Table  5:  Trace  of  the  query  processing  using  OSS  for  the  example  in  Figure  5 


Theorem  1  Proposed  strategy  OSS  is  complete  and  correct,  i.e.,  OSS  can  find  all  objects  satisfying  the 
direction  predicate  and  all  the  objects  in  the  resultSet  satisfy  the  given  direction  predicate. 
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Proof:  OSS  first  constructs  dpRegion  as  an  OpenShape,  and  then  use  function 

dpRegion.  interior  Inter  sects  to  exclude  objects  whose  interiors  do  not  intersect  with  the  interior 
of  dpRegion.  In  other  words,  OSS  only  excludes  MBRs  of  objects  which  do  not  intersect  the  interior 
of  the  corresponding  direction  region,  namely,  MBRs  of  the  objects  which  do  not  satisfy  the  direction 
predicate.  This  guarantees  completeness,  i.e. ,  if  MBR  of  an  object  satisfies  the  given  direction  predicate, 
then  its  MBR  will  not  be  eliminated  by  OSS. 

An  object  is  added  to  the  resultSet  if  and  only  if  the  MBR  of  the  object  interior  Inter  sects  dpRegion. 
As  we  discussed  in  previous  section,  the  interior  of  dpRegion  represents  the  actual  direction  region 
satisfying  the  corresponding  direction  predicate.  If  the  MBR  of  the  target  object  A  interiorlntersects 
dpRegion,  MBR  of  A  must  satisfy  the  directional  relationship.  Therefore,  all  the  MBR-objects  in 
resultSet  must  satisfy  the  direction  predicate,  guaranteeing  correctness.  ■ 

We  now  provide  the  definition  of  new  ADT  OpenShape.  OpenShape  is  defined  as  a  base  class 
hierarchy  to  represent  open  geometries  whose  boundaries  are  not  closed.  We  focus  on  the  data  types 
that  are  needed  to  model  open  direction  region.  The  function  interfaces  for  OpenShape  related  to  the 

processing  of  direction  queries  can  be  defined  in  C++  notation  as  follows: 
class  OpenShape  { 
public : 

virtual  Boolean  interiorlntersects (Geometry)  const; 
virtual  Boolean  overlaps (Geometry)  const; 
virtual  Boolean  contains (Geometry)  const; 
virtual  Boolean  crosses (Geometry)  const; 

}; 

In  the  following,  we  will  discuss  the  OpenShape  and  its  derived  classes  and  use  these  classes  to 
represent  direction  region  for  each  direction  predicate  in  the  defined  predicate  set. 

3.1.1  Defining  OpenShape 

Open  shapes  refer  to  the  geometries  whose  boundaries  are  partially  defined.  Open  shape  objects  have 
infinite  interiors  and  extend  beyond  the  boundary  of  the  embedding  world.  Figure  8  shows  some  examples 
of  open  shapes  that  are  useful  for  processing  direction  queries.  Figure  8(a)-(b)  are  open  lines  with  one- 


,  V 

u 

p 

,  u 

P 

V 

v  r 

P2 

V 

fa)  (b)  (c)  (d)  (e) 

Figure  8:  Examples  of  open  shapes  useful  in  processing  direction  queries 

end  and  two-end  open  respectively,  while  (c)-(e)  are  open  rectangles.  Note  that  in  figure  7,  the  direction 
region  for  each  direction  predicate  is  an  open  rectangle. 

The  boundary  of  an  open  shape  is  a  set  of  geometries  of  the  next  lower  dimension.  The  boundary  of 
an  one-end  open  line  consists  of  the  only  endpoints,  and  the  boundary  of  an  two-end  open  line  is  empty. 
The  boundary  of  an  open  rectangle  consists  of  the  set  of  sides  which  could  be  either  line  segments  or 
open  lines.  The  interior  of  an  open  shape  consists  of  those  points  of  the  open  shape  that  remains  when 
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the  boundary  is  removed.  For  instance,  the  interior  of  an  one-end  open  line  is  the  set  of  points  on  the 
line  except  the  endpoints,  and  the  interior  of  a  two-side  open  rectangle  is  the  rectangle  region  which 
removes  the  boundary  and  indefinitely  extending  to  the  two  other  directions  without  boundary. 

It  would  be  useful  if  there  were  corresponding  object  classes  so  that  users  can  use  open  shapes  at 
abstract  level.  The  new  ADT  OpenShape  is  defined  as  a  base  class  of  open  shapes.  New  data  types  for 
open  lines  and  open  rectangles  can  be  defined  as  derived  classes  of  OpenShape,  and  the  attributes  can  be 
described  using  directions  and  points.  Table  6  defines  ADT  for  each  type  of  open  shapes  shown  in  figure 
8.  In  the  table,  we  only  show  the  attributes  and  constructors  of  each  open  shape  class.  Examples  for 
respective  data  types  using  parts  of  figure  8  are  provided  in  the  last  column  of  the  table.  An  OpenLinel 


ADT 

attributes 

constructors 

examples  in  figure  8 

OpenLinel 

Start-Point  :  Point-, 
dir  :  Direction-, 

OpenLinel(Point,  Direction); 

8(a):  OpenLinel(P,v) 

OpenLine2 

interPoint  :  Point-, 
dir  :  Direction-, 

OpenLine2(Point,  Direction); 

8(b):  OpenLine2(P,v) 

OpenRectl 

vertex  i  :  Point.-, 
vertex2  ■  Point-, 
dir  :  Direction; 

OpenRectl(Point,  Point,  Direction); 

8(c):  OpenRect-l(Pi,  P2,v) 

OpenRect2 

startPoint  :  Point; 
dir  1  :  Direction; 
dir 2  :  Direction; 

OpenRect2 (Point,  Direction, 
Direction); 

8(d):  OpenRect-2{P,u,v) 

OpenRect3 

line  :  OpenLine2; 
dir  :  Direction; 

OpenRect3(OpenLine2, Direction) ; 

8(e):  OpenRect.3(OpenLine2(P,u),v) 

Table  6:  Abstract  Data  Types  for  Open  Lines  and  Open  Rectangles 


is  defined  by  its  endpoint  and  extending  direction,  and  an  OpenLine2  extending  both  ends  and  needs 
an  intermediate  point  and  a  direction  to  describe  it.  The  attributes  needed  to  represent  OpenLinel  and 
OpenLine2  are  identical.  The  difference  between  them  shows  up  in  the  definitions  of  various  operations. 

Three  new  data  types  are  defined  for  the  three  subtypes  of  open  rectangles.  OpenRectl  is  an  one-side 
open  rectangle(e.g.  figure  8c)  described  by  two  endpoints  of  the  rectangle  and  one  direction  representing 
the  open  direction.  OpenRect2  is  a  two-side  open  rectangle(e.g.  figure  8d)  described  by  an  endpoint 
and  an  ordered  pair  of  directions.  OpenRect3  is  a  half  plane  or  three-side  open  rectangle(e.g. figure  8e) 
and  could  be  defined  by  an  OpenLine2  and  a  direction. 

3.1.2  Interpreting  Direction  Predicates  using  OpenShape 

After  defining  the  ADTs  for  open  lines  and  open  rectangles,  we  can  construct  the  open  direction  region 
for  each  direction  predicate.  As  illustrated  in  figure  7,  the  direction  region  of  each  object-orientation- 
based  direction  predicate  is  of  type  OpenRectl  or  OpenRect2.  For  instance,  the  direction  region  for  the 
EF  predicate  is  an  OpenRectl.  A  summary  of  the  correspondence  between  direction  regions  and  their 
OpenShapes  is  shown  in  table  10.  Appendix  B  shows  similar  correspondence  for  point-based  direction 
predicates. 

By  representing  each  direction  region  as  an  OpenShape,  we  process  direction  predicates  using  topo¬ 
logical  relationship  between  MBR  objects  and  OpenShapes.  This  is  the  basic  idea  behind  the  proposed 
OSS  strategy.  When  the  direction  region  of  a  predicate  is  an  open  rectangle,  the  predicate  is  satis¬ 
fied  if  and  only  if  the  target  object  interior  Inter  sects  the  corresponding  open  rectangle.  For  example, 
RF(A,B)  return  TRUE2  if  and  only  if  A  is  interiorlntersected  with  OpenRect‘2(Brf,  right,  front).  We 
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Predicates 

Type  of  Open  Shape 

Predicate  true  iff  A  inter  Inter  sects  the  follow¬ 
ing  open  regions 

EF)A,B) 

OpenRectl 

1-side  open  rectangle 

OpenRectl(B[f,  Brf,  front) 

EB(A,B) 

OpenRectl(Bnj ,  Brh,  front-reverse))) 

ER)A,  B) 

OpenRectl(Br  f,Brb,  right) 

EL)A,B) 

OpenRectl) Br  f,  Bri,,  right-reverse))) 

RF)A,  B) 

OpenRect2 

2-side  open  Rectangle 

OpenRect2(Br  f ,  right,  front) 

LF(A,B) 

OpenRect2(B[f,  right. reverse)),  front) 

RB(A,B) 

OpenRect2(Brh,  right,  front. reverse))) 

LB)A,  B) 

OpenRect2)Bn,, right-reverse)),  front. reversed 

Table  7:  Open  shape  representation  for  direction  regions 


will  discuss  the  topological  operations  next. 

3.2  Topological  Operations  on  Open  Shapes 

In  this  section,  we  will  focus  on  defining  a  topological  operation,  namely,  interior  Intersects,  since  this 
operation  is  needed  to  solve  direction  predicates  as  shown  in  table  10.  We  define  interior  Inter  sects{  open 
shape  O,  closed  shape  C),  where  O  could  be  an  OpenRectl  or  an  OpenRect2,  and  closed  shape  C  could 
be  a  rectangle.  The  implementation  of  interior  Inter  sects  uses  two  other  topological  operations  of 
contains  and  crosses ,  which  are  defined  in  Appendix  C.  Other  possible  topological  operations  (e.g. 
touches ,  disjoint[  12])  may  be  addressed  in  future  work.  In  the  rest  of  this  section,  O  refers  to  an  open 
shape,  C  refers  to  a  closed  rectangle.  The  algorithm  may  apply  to  more  general  cases  of  C  such  as  simple 
convex  polygon. 

3.2.1  The  interior  Inter  sects  Operation 

The  interiorlntersects  operation  is  defined  for  (OpenRectl,  rectangle)  and  (OpenRect2,  rectangle) 
situations.  For  any  such  pair  of  open  shape  O  and  closed  shape  C,  the  interiorlntersects  relation 
between  them  is  defined  as: 

O .interior Intersects(C)  =  TRUE  interior(C)  f]  interior(O)  yf  0 
The  semantics  of  interior  Inter  sects  covers  two  topological  operations,  contains  and  overlaps ,  defined  in 
OGIS[12]  for  closed  geometry  pairs.  In  other  words,  O.interiorlntersects(C)  is  true  if  C  is  contained  in  O, 
or  C  overlaps  O.  Since  a  closed  object  C  cannot  contain  an  open  object  O  due  to  infinite  extent,  we  don’t 
have  to  check  for  C  contains  O.  We  will  discuss  the  implementation  of  the  OpenRectl. interiorlntersects^ 
Rectangle)  and  OpenRect2.fnteriormtersects(Rectangle)  respectively. 

The  interiorlntersects  Operation  for  OpenRectl 

An  OpenRectl  interiorlntersects  a  rectangle  if  there  exists  a  set  of  points  which  belong  to  both  the 
interior  of  the  OpenRectl  and  the  interior  of  the  rectangle.  Figure  9  shows  several  situations  that  an 
OpenRectl  interiorlntersects  a  rectangle. 

The  boolean  value  of  interiorlntersects  operation  can  be  determined  by  enumerating  all  possibilities 
of  the  interiorlntersecting  relationship  between  an  OpenRect  l  and  a  rectangle.  O  .interior  Intersects(R) 

2Note  that  the  boolean  value  of  a  topological  operations  between  a  closed  shape  and  an  OpenShape  can  be  determined 
without  looking  at  the  boundary  of  embedding  world[21]. 
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oprectl  .contains(p) 
(a)  one  endpoint  inside 


oprect  1  .contains(rec) 

(b)  all  endpoints  on  bundary 


opline  la.crosses(rec)  || 
opline  lb.crosses(rec) 

(c)  at  least  one  ednpoint  outside 


rec.contain(endp2) 
rec.contain(endp  1 ) 

(d) 


Figure  9:  OpenRectl  interior  Inter  sects  a  rectangle 


is  TRUE  if  and  only  if  at  least  one  of  the  following  three  conditions  is  true: 

•  At  least  one  of  the  endpoints  of  R  is  contained  in  0(e.g.  figure  9(a)); 

•  All  endpoints  of  R  are  on  the  boundary  of  0(figure  9(b)). 

•  At  least  one  endpoint  of  P  is  outside  0(figure  9(c))  and  at  least  one  OpenLinel  of  the  two  Open- 
Linels  boundary  of  O  crosses  R,  i.e.,  OpenLinel(0.endpl,  O.dir)  crosses  R  or  0penLinel(0.endp2, 
O.dir)  crosses  R. 

The  first  case  can  be  tested  by  using  OpenRectl.  contains  (Point)  operation,  and  the  second  case  is 
checked  by  OpenRectl. contains(Rectangle)  operation.  Both  operations  are  described  in  AppendixC.2. 
The  third  case  is  checked  by  using  OpenLinel. crosses(Rectangle)  operation  defined  in  AppendixC.l. 

Efficient  implementation  of  interior  Inter  sects  operation  may  be  other  fast  filter  to  reduce  computa¬ 
tion  of  above  three  tests.  For  example,  if  any  of  the  endpoints  of  O  is  within  R,  then  interior  Inter  sects 
operation  can  be  determined  to  be  true  without  further  tests.  This  is  illustrated  in  Figure  9(d).  This 
strategy  is  useful  for  some  special  polygon,  such  as  MBR,  where  the  M BR.contains(Point)  operation 
is  cheaper.  The  pseudo-code  for  the  interior  Intersects  operation  is  described  as  Algorithm  4. 


The  interior  Intersects  Operation  for  OpenRect2 

OpenRect‘2.interiorIntersects(Recta.ngle )  is  TRUE  if  there  exists  a  set  of  points  which  belong  to  both 
the  interior  of  the  OpenRect2  and  the  interior  of  the  rectangle.  Figure  10  shows  several  possible  situations 
that  an  OpenRect2  interior  Inter  sects  a  polygon.  Similar  to  the  operation  for  OpenRectl,  The  boolean 


opline  1  a 


oprect2 .  contain(p);  oprect2 .  contain(p); 

(a)  at  lease  one  endpoint  inside 


opline  1  a.crosses(rec)  || 
opline  1  b  .crosses(rec) 

(b)  at  least  one  endpoint  outside 


polygra 


oprect2 


polygon.contain(startPoint) 

(d) 


Figure  10:  An  OpenRect2  interior  Inter  sects  a  Polygon 
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Algorithm  4  OpenRectl  interim’ Inter  sects  a  rectangle 

Input:  rec  is  the  rectangle  that  needs  to  be  checked; 

the  current  OpenRectl  object,  which  has  attributes  (endpl,endp2,dir)\ 
Output:  TRUE  if  interiorlntersects,  FALSE  otherwise 

OpenRectl::interiorIntersect.s(Rectang\e  rec)  { 

/* *  case  1,  figure  9(a)  */ 
for  each  ep  6  endpoints  of  rec 
if  (contains(ep)) 

return  TRUE; 

/*  case  2,  figure  9(b)  */ 
if  (contains(rec)) 
return  TRUE; 

/*  case  3,  figure  9(c)  */ 
oplinela  =  OpenLinel(endpl,  dir); 
oplinelb  =  OpenLinel(endp2,  dir); 
if  (  oplinela. crosses(rec)  ||  oplinelb. crosses(rec)  ) 
return  TRUE; 

return  FALSE; 

} 


value  of  OpenRect2.interiorIntersects(Rectangle)  operation  can  be  determined  by  enumerating  all 
possibilities  of  the  relationship  between  an  OpenRect2  and  a  rectangle.  0.interiorIntersects(R)  is 
TRUE  if  and  only  if  at  least  one  of  the  following  two  conditions  is  true: 

•  At  least  one  of  the  endpoints  of  R  is  contained  in  0(e.g.  figure  10(a)); 

•  At  least  one  endpoint  of  P  is  outside  0(figure  10(b))  and  at  least  one  OpenLinel  of  the  two 
OpenLinels  boundary  of  O  crosses  R,  i.e.,  OpenLinel(0.startPoint,  O.dirl)  crosses  R  or  Open- 
Line  1(0.  startPoint,  0.dir2)  crosses  R. 

The  first  case  can  be  tested  by  using  OpenRect2.contains(Point )  operation  described  in 
AppendixC.2.  The  second  case  is  checked  by  using  OpenLinel. crosses{Rectangle)  operation  de¬ 
fined  in  AppendixC.l.  Note  that  for  OpenRect2,  the  endpoints  of  any  rectangle  can  not  be  all 
on  the  boundary  of  the  OpenRect2,  the  above  two  cases  are  complete.  Efficient  implementation  of 
OpenRect2.interiorIntersects(rectangle)  operation  may  be  possible  to  use  fast  filter,  figure  10(c)  illus¬ 
trates  a  cheap  checking  for  special  rectangles  such  as  MBRs.  The  pseudo-code  is  described  by  algorithm 
5. 

Lemma  2  Algorithm  OpenRectl::interiorIntersects  and  OpenRect2::  interiorlntersects  are 

complete  and  correct. 

Proof:  Figure  11  shows  the  flow  chart  of  algorithm  4.  The  algorithm  tests  three  cases,  and  it  returns 
TRUE  if  and  only  if  at  least  one  of  these  three  conditions  is  true.  This  guarantees  the  correctness  of  the 
algorithm,  i.e.,  the  algorithm  returns  TRUE  only  if  the  OpenRectl  interiorlntersects  the  rectangle. 

Plane  sweep  strategy  can  help  to  prove  the  completeness  of  the  algorithm.  Let’s  consider  a  pair 
of  disjoint  OpenRectl  and  rectangle  as  illustrated  in  figure  12(a).  Move  the  rectangle  horizontally 
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Algorithm  5  0penRect2  interim’ Inter  sects  Rectangle 

Input:  rec  is  the  rectangle  that  needs  to  be  checked; 

the  current  OpenRect2  object,  which  has  attributes  ( startPoint,dirl,dir2)\ 
Output:  TRUE  if  interiorlntersects,  FALSE  otherwise 

OpenRect2::interiorlntersects(Polygon  aPolygon)  { 

/*  case  1,  figure  10(a)  */ 
for  each  ep  6  endpoints  of  aPolygon 
if  (contains(ep)) 

return  TRUE; 

/*  case  2,  figure  10(b)  */ 
oplinela  =  OpenLinel(startPoint,  dirl); 
oplinelb  =  OpenLinel(startPoint,  dir2); 

if  (  oplinela. crosses(a Polygon)  ||  oplinelb. crosses(a Polygon)  ) 
return  TRUE; 

return  FALSE; 

} 


Figure  11:  control  flow  of  the  algorithm 


and  the  first  case  rectangle  touches  the  OpenRectl  is  illustrated  in  12(b).  When  continuously  moving 
the  rectangle  horizontally,  OpenRectl  interiorlntersects  the  rectangle,  and  the  relationship  between 
OpenRectl  and  Rectangle  falls  into  the  three  cases  in  the  flow  chart.  This  guarantees  the  completeness  of 
the  algorithm,  i.e.,  the  algorithm  returns  FALSE  only  when  there  is  no  intersection  between  the  interior 
of  OpenRectl  and  the  interior  of  the  rectangle. 

The  arguments  of  completeness  and  correctness  for  the  algorithm  OpenRect2::interiorIntersects  are 
similar.  ■ 

4  Algebraic  Analysis 

In  this  section,  we  perform  algebraic  analysis  for  the  relative  performance  of  the  proposed  open  shape 
based  strategy  (OSS)  vs.  the  classical  range  query  strategy  (RQS).  We  will  first  give  a  cost  model  for  OSS 
and  RQS,  and  then  characterize  the  analysis  in  terms  of  theorems  and  lemmas.  Since  the  performance  is 
similar  for  the  predicates  whose  direction  regions  correspond  to  the  same  OpenShape  type,  the  analysis  is 
performed  in  terms  of  two  types  of  predicates,  namely,  the  predicates  whose  direction  regions  correspond 
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FALSE  FALSE  TRUE(case  3)  TRUE(case  1) 

Figure  12:  Possible  relationships  between  OpenRectl  and  Rectangle 


to  OpenRect  l  and  the  predicates  whose  direction  regions  correspond  to  OpenRect2.  In  the  rest  of  the 
paper,  we  refer  the  first  predicate  type  as  EF-type ,  and  the  second  as  LF-type.  Examples  of  EF-type 
predicates  include  EF,  EB,  ER,  and  EL.  Examples  of  LF-type  predicates  include  LF,LB,  RF,  and  RB. 


I/O  Cost  Models 

The  I/O  cost  of  a  query  is  evaluated  in  terms  of  the  number  of  page  accesses  needed  in  order  to  solve  the 
query.  RQS  accesses  the  R-tree  pages  whose  MBR  interiorlntersects  the  MBR  of  the  direction  region, 
while  OSS  accesses  the  R-tree  pages  whose  MBRs  interiorlntersects  the  actual  direction  region.  Figure 


dpRegion 

gp  dpMBR 


LB 

dpRegion 


dpMBR 


World  Boundary 


Figure  13:  The  ratio  of  RQS  vs.  OSS 

13  illustrates  the  direction  region  and  their  corresponding  MBRs  for  predicates  EF  and  LB.  The  shadow 
regions  are  actual  direction  regions  and  the  dashed  rectangles  are  MBRs  of  the  direction  regions.  We 
first  make  the  following  assumptions  before  we  introduce  the  cost  model: 

•  Data  objects  are  uniformly  distributed  on  embedding  space. 

•  size  of  MBR  objects  <§;  size  of  world 

•  size  of  MBR  objects  <C  size  of  direction  regions 

Let  dpRegion(dp)  represent  the  actual  direction  region  for  direction  predicate  dp,  and  dpMBR(dp) 
refer  to  the  MBR  of  dpRegion(dp).  Under  above  assumptions,  the  number  of  R-tree  pages  whose  MBR 
interiorlntersects  dpRegion  can  be  approximated  by  the  area  of  the  dpRegion.  Similarly,  the  number  of 
R-tree  pages  whose  MBR  interiorlntersects  dpMBR  can  be  approximated  by  the  area  of  the  dpMBR. 
This  is  accurate  when  objects  are  uniformly  distributed  over  the  space  and  the  object  sizes  are  much 
smaller  than  the  sizes  of  direction  regions.  In  general  these  assumptions  do  not  hold,  nevertheless,  this 
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simple  model  is  useful  in  understanding  the  relative  performance  of  the  two  strategies  OSS  and  RQS. 
Formally,  the  I/O  cost  is  approximated  as  follows: 

I/O  cost(0SS,  dp)  ps  area(dpRegion(dp) ) ; 

I/O  cost(RQS,  dp)  area(dpMBR(dp) )=area(MBR(dpRegion(dp) ) ) ; 

The  following  lemmas  and  theories  characterize  the  performance  properties  using  this  cost  model 
under  same  assumptions. 

Lemma  3  The  following  statement  for  I/O  cost  is  true  for  processing  any  direction  predicate  dp. 

I/O  cost(OSS,  dp)  <  I/O  cost(RQS,  dp); 

Proof:  By  definition  of  MBR,  for  any  polygon  P,  area(P)  <  area(MBR(P)).  Considering  P  =  dpRe- 
gion(dp)  for  any  predicate  dp,  we  have  area(dpRegion(dp))  <  area(MBR(dpRegion(dp)).  ■ 

Lemma  4  For  any  EF-type  predicate  dp  in  {EF,EB,EL,ERj ,  the  I/O  costfOSS,  dp)  and  I/O  cost(RQS, 
dp)  can  be  approximated  as  follows: 

I/O  cost(0SS,dp)  =^g;  (0°  <  8  <  45°) 

=  ;  (45°  <9  <  90°) 

I/O  cost(RQS,dp)  =  as  cos#  +  a2  tan#;  (0°  <  8  <  45°) 

=  as  sin#  +  a2  cot  6;  (45°  <  6  <  90°) 

where  a  =  the  distance  from  the  centroid  of  the  reference  object  to  the  global  boundary  that  intersects 
the  dpRegion,  s  =  size  of  the  reference  object  orthogonal  to  the  direction  of  dp,  6  =  angle  between  direction 
of  dp  and  x-axis. 

Proof:  Recall  the  assumption  that  s  «  a.  Assume  that  the  reference  object  is  at  the  centroid  of  a 
square-shape  embedding  space  for  simplicity.  The  change  of  orientation  of  the  reference  object  leads 
to  three  different  cases:  dpRegion  intersects  with  a  boundary  on  X  dimension(figure  14(a));  dpRegion 
intersects  with  a  boundary  on  Y  dimension  (figure  14(b));  dpRegion  intersects  with  the  boundary  on  both 
dimensions  (figure  14(c)).  Since  the  reference  object  is  located  at  the  center  of  the  embedding  space,  case 


(a)  case  1:  Intersect  with 
boundary  on  X  dimension 


(b)  case  2:  Intersect 
with  boundary  on  Y 
dimension 


(c)  case  3:  Intersect  on 
both  dimensions 


Figure  14:  Three  cases  for  different  orientations 


1  corresponds  to  the  situation  of  0  <  8  <  45°,  case  2  corresponds  to  the  situation  of  90°  >  6  >  45°, 
and  in  case  3 ,  0  — »  45°.  The  exact  boundaries  of  the  three  cases  are  sensitive  to  the  ratio  s/a.  Since  we 
assume  s  «  a  for  simplicity,  case  3  can  be  approximated  by  either  case  1  or  case  2  for  0  =  45°. 
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case  l(14(a)):  area(dpMBR)  =  a(y i  +  y/)  =  a(s  cos #  +  a  tan#); 
areafdpRegion)  <  sh  = 

case  2(  14(b)) :  area(dpMBR)  =  a(s  sin#  +  acotO)  =  as  sin#  +  a 2  cot#; 
area(dpRegion)  <  sh  = 


Theorem  2  For  any  EF-type  predicate  dp  £{EF,  EB,  EL,  ER},  for  a  fixed  size  of  reference  object  located 
in  the  center  of  the  embedding  space,  the  maximum  I/O  improvement  is  achieved  when  6  =  j  +  k  x  f  (k 
is  an  integer),  while  the  minimum  improvement  is  obtained  when  6  =  f  x  k(k  is  an  integer). 

Proof:  According  to  lemma  4,  the  I/O  cost  ratio  can  be  approximated  using  one  of  the  two  formulas 
according  to  the  orientation  of  the  reference  object: 

I/O  cost  ratio  =  =  7  sin#  +  cos2  #;  (0°  <  8  <  45°) 

=  f  cos#  +  sin2#;  (45°  <  #  <  90°) 

Figure  15  shows  the  I/O  cost  ratio  curve  for  orientation  degree  #  in  the  range  of  [0,90°],  for  some 
fixed  values  of  s  and  a.  We  can  notice  that  the  maximum  value  of  the  I/O  ratio  is  achieved  when  #  =  45°, 
and  the  minimum  ratio  is  obtained  when  #  =  0°  and  90°.  We  can  also  differentiate  the  functions  for  I/O 


Figure  15:  The  I/O  ratio  curve  for  #  €  [0°,  90°]  according  to  lemma  4 
cost  ratio  to  verify  the  maximum  and  minimum  point. 


Lemma  5  For  any  EF-type  predicate  dp  (z{EF,  EB,  EL,  ER),  I/O  cost  ratio  is  affected  by  the  size  of 
reference  objects.  The  smaller  the  object  size,  the  larger  the  I/O  improvement  ratio. 


Proof:  According  to  lemma  4,  we  have, 

1/0  cost  ratio  =  ^ oZh[rqs’X )  =  f  sin#  +  cos2  # ;  (0°  <  #  <  45°) 

=  |  cos#  +  sin2  #;  (45°  <  #  <  90°) 

Since  in  the  range  of  0  <  #  <  90°,  both  cos(8)  and  sin(8)  are  greater  than  0.  Therefore,  when 
parameters  a  and  #  are  fixed,  the  decrease  of  s  results  into  the  increase  of  I/O  cost  ratio. 

For  any  predicate  dp  6  {  LF,LR,RF,RB),  the  I/O  cost  ratio  is  between  1  and  2,  the  maximum  ratio 
is  achieved  when  8  =  j  +  k  x  ■ |(k  is  an  integer).  The  argument  for  this  is  similar. 
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5  Experimental  Evaluation 

5.1  Experiment  Design 

We  now  design  an  experiment  to  compare  the  performance  of  classical  range  query  strategy(RQS)  with 
the  performance  of  open  shape  based  query  strategy(OSS)  for  the  predicate  set  defined  in  Table  4.  We 
use  several  randomly  generated  datasets  which  contain  MBRs  of  data  objects  with  varying  sizes.  The 
query  file  containing  the  reference  object  MBRs  has  1500  objects.  Example  dataset  and  reference  object 
set  are  shown  in  figure  16. 
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(a)  Dataset  R-tree  without  overlap  (b)  Dataset  R-tree  with  overlap 
among  objects  among  objects 


Figure  16:  Example  of  datasets 


(c)  Set  of  reference  Object  MBRs 
with  orientation  degree=90° 


A  set  of  queries  are  selected  to  cover  different  types(LF-type  and  EF-type)  of  direction  predicates. 
LF  family  includes  the  predicates  of  LF,  LB,  RF,  RB.  EF  family  includes  the  predicates  of  EF,  EB, 
ER,  EL.  On  average,  selectivity  of  EF  family  predicates  is  lower  than  that  of  LF  family  predicates.  We 
consider  the  following  queries: 


•  Query  Ai:  Given  a  reference  object,  find  all  objects  that  are  EF  of  it. 

•  Query  A2:  Given  a  reference  object,  find  all  objects  that  are  EB  of  it. 

•  Query  A3:  Given  a  reference  object,  find  all  objects  that  are  ER  of  it. 

•  Query  A4:  Given  a  reference  object,  find  all  objects  that  are  EL  of  it. 

•  Query  Bi:  Given  a  reference  object,  find  all  objects  that  are  LF  of  it. 

•  Query  B2:  Given  a  reference  object,  find  all  objects  that  are  LB  of  it. 

•  Query  B3:  Given  a  reference  object,  find  all  objects  that  are  RF  of  it. 

•  Query  B4:  Given  a  reference  object,  find  all  objects  that  are  RB  of  it. 
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The  predicates  in  query  A i  are  of  EF-type,  and  the  direction  predicates  involved  in  query  Bi  are  of 
LF-type.  In  general,  query  A i  has  lower  selectivity  than  query  Bi. 

The  variable  parameters  for  the  experiment  include  the  orientation  of  reference  objects,  overlap 
degree  among  objects  in  the  dataset,  the  size  of  reference  objects  and  the  number  of  objects  in  the 
dataset.  The  metrics  for  evaluation  include  the  number  of  page  accesses  and  the  number  of  operations 
required  by  each  strategy  to  retrieve  the  query. 

The  orientation  of  a  reference  object  is  defined  as  the  angle  between  front  direction  of  the  object  and 
the  x-axis  of  the  global  coordinate  system.  When  the  orientation  is  equal  to  90°,  the  front  direction  of 
the  reference  object  is  parallel  to  the  north  direction  in  the  absolute  reference  frame.  In  our  experiment, 
orientation  varies  from  0°  to  180°. 

The  overlap  degree(OPD)  between  two  objects  is  defined  as  the  ratio  of  the  area  of  overlapping 
region  to  the  area  of  the  smaller  object.  The  overlap  degree  between  objects  A  and  B  is  calculated  as 
OPD  =  min(arla(Afarea(B))  -  The  overlap  degree  of  the  dataset  is  defined  as  the  average  overlap  degree 
of  the  non-disjoint  object  pairs  in  the  dataset. 

The  size  of  the  reference  object  is  measured  as  the  relative  size  of  the  reference  object  to  the  global 
size.  The  size  varies  from  ^  to  ^  of  the  global  size. 

Figure  17  shows  various  steps  of  the  experiment.  Given  the  range  of  object  size  and  the  overlap 
degree,  the  data  set  is  randomly  generated,  and  the  R-tree  of  the  dataset  is  created  based  on  the  given 
branching  factor.  The  set  of  reference  objects  is  randomly  generated  according  to  its  size  range,  which 
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Figure  17:  Experimental  setup  and  design 

can  be  either  equal  to  the  size  range  of  dataset  or  independently  given.  Using  R-tree  and  reference  object 
set  as  input,  “Query  processing”  simulates  the  behaviors  of  the  RQS  and  OSS  algorithms  for  different 
direction  predicates.  The  total  number  of  page  accesses  and  the  number  of  operations  are  tracked  for 
each  combination  of  algorithm,  overlap  degree,  the  orientation  and  size  of  reference  objects  and  the 
dataset  size  to  derive  the  experiment  results. 

5.2  Experiment  Results 

Figure  18,  19,  20  and  21  show  the  comparison  between  the  classical  range  query  strategy  (RQS)  and  the 
proposed  open  shape  based  strategy(OSS)  for  I/O  costs  and  CPU  costs.  I/O  cost  is  measured  in  terms 
of  the  number  of  distinct  pages  fetched  from  disk.  CPU  cost  is  measured  in  terms  of  number  of  distinct 
line-line  intersection  operations  used  by  an  algorithm.  Since  the  performance  is  similar  for  the  predicates 
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of  same  types,  we  only  show  two  curves  representing  the  relative  performance  of  OSS  and  RQS  for  two 
different  predicate  types  in  each  figure.  The  curve  denoted  by  “EF/ER/EB/EL”  illustrates  the  average 
relative  performance  improvement  for  EF-type  predicates.  The  curve  denoted  by  “LF/LB/RB/RB” 
illustrates  the  average  relative  performance  improvement  for  LF-type  predicates.  For  any  predicate  dp, 
the  relative  performance  is  defined  as  the  ratio  cost(RQS,dp)/cost(OSS,dp).  Ratio  >  1  means  that  OSS 
is  cheaper  than  RQS. 

The  common  observation  in  all  figures  is  that  OSS  performs  better  than  RQS  both  in  terms  of  the 
number  of  page  accesses(I/0)  and  the  number  of  operations(CPU).  For  low  selectivity  predicates  such 
as  EF-type  the  performance  of  OSS  is  even  better  compared  to  RQS. 

5.2.1  Orientation  of  the  reference  object 

Figure  18  shows  the  impact  of  the  orientation  of  reference  objects.  The  dataset  consists  of  42875  spatial 
objects  without  overlap.  We  use  1500  different  reference  objects  with  identical  orientations,  and  the  size 
of  each  object  equals  one  percent  of  the  world.  The  orientations  of  reference  objects  vary  from  0°  to 
180°,  at  an  interval  of  15  degrees.  Recall  the  orientation  of  an  object  is  measured  by  the  angle  between 
its  front  direction  and  the  x-axis  of  the  global  coordinate  system.  Figure  18  (a)  and  18(b)  show  the 
average  page  accesses  and  operations  performed  across  1500  reference  objects  respectively.  OSS  and 


(a)  Effect  on  Number  of  Page  access 


Orientation:  Degree  between  front  axis  and  x  axix 

(b)  Effect  on  the  Number  of  Operations 


Figure  18:  Effects  of  orientations  of  reference  objects(orientation:  0°,  15°,  •  ■  ■ ,  180°,  overlap  degree  of 
the  data  set  =  0,  reference  object  size  =  1%  of  global  size,  dataset  size  =  42875) 


RQS  have  the  same  I/O  and  CPU  cost  when  the  orientation  is  0°,  90°,  or  180°  with  the  cost  ratio  equal 
to  1.  OSS  performs  better  than  RQS  for  most  orientations  with  best  relative  performance  for  OSS  at 
45°  and  135°.  Relative  performance  advantage  of  OSS  for  predicates  of  EF-type  varies  cyclically.  This 
result  is  consistent  with  Theorem  2  in  section  4. 


5.2.2  The  size  of  reference  objects 

Figure  19  shows  the  effect  of  the  size  of  the  reference  object  on  the  I/O  and  CPU  performance  with  fixed 
orientation,  and  fixed  dataset.  The  dataset  has  42875  objects.  We  use  1500  different  reference  objects 
without  overlap  and  with  fixed  orientation  of  30°.  The  choice  of  orientation  is  arbitrary.  We  vary  size  of 
reference  objects  taking  values  of  ,  ph) ,  ^ ,  ■  ■  ■ ,  -T  of  the  total  world.  The  x-axis  in  Figure  19  shows 
the  ratio  of  —  global  size  —  thus  the  reference  object  size  of  1%  of  the  world  corresponds  to  100  in 

reference  object  size  7  J  ^ 
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x-axis.  Note  that  relative  gain  of  OSS  for  size  =  1%  is  consistent  with  the  relative  gain  in  Figure  13  for 
orientation  of  30°.  Obviously,  OSS  consistently  outperforms  RQS.  The  relative  performance  advantage 
for  the  EF-type  predicates  increases  steadily  with  the  decrease  of  the  reference  object  size.  This  is 
consistent  with  Lemma  5. 


(a)  Effect  on  the  number  of  page  access 


(b)  Effect  on  the  number  of  operations  per¬ 
formed 


Figure  19:  Effects  of  the  size  of  reference  objects  (orientation:  30°,  overlap  degree  of  data  set  =0,  dataset 
size  =  42875  objects,  the  size  of  reference  object  varies  from  pp  to  pj  of  the  global  size) 


5.2.3  Overlap  degree 

Figure  20  shows  the  effect  of  overlap  degree  of  the  dataset  on  the  I/O  and  CPU  performance.  We  used 
1500  different  reference  object  of  fixed  size(l%)  and  fixed  orientation(30°).  Average  overlap  between 
objects  in  the  data  set  varies  from  5  percent  to  60  percent.  Recall  that  overlap  degree  between  two 
objects  is  the  ratio  of  common  area  to  the  smaller  area  of  the  two  objects.  Again,  OSS  consistently 
outperforms  RQS.  The  relative  performance  advantage  of  OSS  diminishes  slightly  with  the  increase  in 
the  overlap  degree  among  objects.  Our  algebraic  cost  models  (section  4)  do  not  predict  the  effect  of 
overlap  degree.  We  propose  to  extend  our  model  towards  this  purpose  in  future  work. 


(a)  Effect  on  Number  of  Page  access 


(b)  Effect  on  Number  of  Operations 


Figure  20:  Effects  of  the  overlap  degree  of  the  data  set  (Orientation  =  30°,  the  size  of  reference  object 
=  %1  of  global  size,  dataset  size  =  42875,  overlap  degree=0, 0.05,  •  •  • ,  0.6) 
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5.2.4  The  number  of  objects  in  dataset 


Figure  21  shows  the  effect  of  the  number  of  objects  in  dataset  on  I/O  and  CPU  performance.  We  used 
1500  different  reference  object  of  fixed  size(l%)  and  fixed  orientation(30°).  The  objects  in  dataset  have 
no  overlap.  The  dataset  size  varies  from  8000  to  125000.  The  relative  performance  of  OSS  improves  with 
the  increase  in  the  number  of  objects  in  dataset.  This  result  demonstrates  that  algorithm  OSS  scales 
better  than  RQS  as  the  size  of  dataset  increases.  Our  cost  model  does  not  explain  why  the  relative 
advantage  of  OSS  over  RQS  improves  with  the  increase  in  dataset  size.  We  would  like  to  address  this 
issue  in  future  work. 


Number  of  data  objects 


Number  of  Data  objects 


(a)  Effect  on  Number  of  Page  access 


(b)  Effect  on  Number  of  Operations 


Figure  21:  Effects  of  the  number  of  objects  in  dataset  (Orientation=30°,  Overlapping  degree  =0,  the 
size  of  reference  object  =  %1  global  size) 


6  Conclusions  and  Future  Work 

In  this  paper,  we  focus  on  processing  queries  based  on  object-orientation-based  directional  relationships. 
Open  Shape  based  Strategy  (OSS)  is  proposed  for  processing  object-orientation-based  direction  queries. 
OSS  models  direction  regions  as  Open  Shapes,  and  uses  actual  direction  region  to  exclude  potential 
false  hits  as  early  as  possible.  Since  OSS  models  the  direction  region  as  an  OpenShape,  it  does  not 
need  to  know  the  boundary  of  the  embedding  world,  thus  eliminating  the  computation  related  to  the 
world  boundary.  The  algebraic  analysis  and  experiment  results  demonstrate  that  the  OSS  consistently 
outperforms  range  query  strategy(RQS)  in  terms  of  both  I/O  and  CPU  cost. 

In  future  work,  we  would  like  to  consider  extending  OSS  to  other  direction  predicate  sets[14,  6,  11]. 
We  would  also  like  to  address  the  processing  of  queries  involving  viewer-orientation-based  direction 
predicates  by  deriving  more  class  and  operations  for  ADT  OpenShape.  We  would  also  like  to  investigate 
processing  orientation-based  direction  queries  in  a  mobile  environment.  Applying  OSS  to  robotics  and 
motion  planning  applications  is  another  direction  of  future  work. 
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A  Abstract  Data  Types  for  Modeling  Direction 

As  a  summary  of  the  above  discussion,  the  definition  of  ADTs  for  vector,  direction  and  orientation  is  given  in  Table  8. 
The  C  — ( — [—  like  syntax  is  used  here.  The  column  labeled  attributes  declares  the  member  variables  of  each  class,  and  the 
representative  operations  column  declares  the  interfaces  of  operations  for  each  class.  The  Direction  class  has  two  attributes 
that  represent  the  two  components  when  the  direction  is  projected  on  the  two  axis  of  the  coordinate  system.  It  can  be 
constructed  from  an  ordered  triple.  Four  operators  are  defined  for  Direction.  The  orientation  class  has  three  member 
variables  which  form  a  Cartesian  coordinate  system.  Translate  and  rotate  are  declared  as  the  member  operator  functions 
of  the  orientation  class. 


25 


ADT 

attributes 

representative  operations 

Direction 

x-comp:  float; 
y-comp:  float; 

constraint  =  unit  magnitude 

Direction(float,  float);  //constructor 
Direction  operator  compose(Direction); 
Direction  operator  reverse(); 
float  operator  deviation(Direction); 
boolean  isBetween(Direction,  Direction); 

Orientation 

OP  :  point; 

above  :  Direction; 
right  :  Direction; 

Orientation(float,  Direction,  Direction); 

/ /  constructor 

orientation  operator  translate(Direction); 
orientation  operator  rotate(rotate-matrix); 

Table  8:  Abstract  Data  Types  for  Direction  and  Orientation 


B  Direction  Predicates  for  Point  Objects 

After  defining  direction  and  orientation  objects  and  operators,  we  now  model  directional  predicates  for  object-based 
reference  system.  We  begin  by  working  on  point  objects,  and  defining  an  example  set  of  direction  predicates  as  shown 
in  table  9.  The  satisfied  directional  region  is  illustrated  in  figure  22.  For  simplicity,  we  restrict  our  discussion  in  two 


Figure  22:  Directional  Predicates  for  Point  Reference  Object 


dimensions,  and  the  orientation  of  the  reference  object  B(Ob)  is  assumed  as  in  figure  22  with  two  orthogonal  direction 
objects  above  and  right  representing  B’s  above  and  right  directions.  The  directions  left  and  below  can  be  represented  as 
right. reverse^)  and  above.rever se()  by  using  the  reverse  operator  of  the  direction  object.  The  discussions  can  be  extended 
to  three  dimensions  by  adding  an  orthogonal  axis  front,  s  we  can  see  from  figure  22,  a  point  reference  object  divides  the 


Direction  predicates 

BA  0  Os-above 

BA  0  Os -right 

SP(A,B) 

0 

0 

EA(A,  B) 

1 

0 

EB(A,B) 

-1 

0 

ER(A,  B) 

0 

1 

EL{A,B ) 

0 

-1 

RA(A,B) 

>  0 

>  0 

LA(A,B) 

>  0 

<  0 

RB(A,B) 

<  0 

>  0 

LB(A,  B) 

<  0 

<  0 

Table  9:  Direction  Predicates  for  Object-based  system 


plane  into  nine  partitions  which  forms  different  direction  regions  with  respect  to  the  orientation  of  the  reference  object. 
The  predicate  set  defined  in  table  9  consists  of  nine  predicates,  each  of  which  corresponds  to  one  of  the  nine  possible 
partitions  that  a  target  object  A  is  located  in.  Each  of  the  four  predicates  EA(A,  B),  EB(A,  B),  EL(A,  B ),  and  ER(A ,  B) 
returns  TRUE  if  and  only  if  point  object  A  is  located  in  the  straight  line  of  the  exactly  above,  below,  right,  and  left  of 
B  respectively.  On  the  other  hand,  direction  range  predicates  RA(A,B),  LA(A,B),  RB(A,B),  and  LB(A,B)  represents 
that  object  A  is  within  the  corresponding  direction  range  of  B  from  B’s  viewpoint.  For  instance,  RA(A,  B)  returns  TRUE 
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if  and  only  if  object  A  is  located  in  the  region  composed  by  two  directions:  Ob- right  and  Ob -above.  All  the  predicates 
are  defined  by  the  deviation  of  direction  objects.  First,  a  direction  object  BA  is  constructed  from  the  vector  A  —  B.  Then 
the  direction  of  point  object  A  with  respect  to  point  object  B’s  orientation  is  decided  by  the  deviation  of  direction  object 
BA  from  the  two  directions  Ob -right  and  Ob -above.  The  vector  dot-product  is  the  meta  operation  for  direction  deviation 
operation. 

Lemma  6  Predicate  set  defined  in  table  9  is  complete,  i.e.  Given  any  pair  of  oriented  points(P,Q),  the  direction  of  P 
with  respect  to  Q  based  on  Q ’s  orientation  can  be  represented  in  terms  of  one  of  the  predicates  in  predicate  set. 

Proof:  The  set  of  directional  region  of  the  corresponding  predicate  set  partitions  the  space  around  the  reference  point 
Q,  i.e.,  any  point  P  in  the  embedded  space  must  be  fall  into  one  of  the  directional  regions,  and  hence  the  direction  of  P 
related  to  Q  can  be  represented  by  one  of  the  predicates  in  the  predicate  set.  The  predicate  set  is  complete.  ■ 

B.l  Interpreting  point-based  direction  predicates  using  Open  Shapes 


Predicates 

Type  of  Open  Shape 

Predicate  true  iff  3  point  P  £  A,  s.t.  P  £  interior 
of  the  following  open  regions 

EF(A,B) 

OpenLinel 
l-end  open  line 

OpenLinel(B,  front) 

EB(A,B) 

OpenLinel(B ,  front.  reverseQ) 

ER(A,B) 

OpenLinel(B,  right) 

EL(A,  B) 

OpenLinel(B,  right. reverseQ) 

RF(A,  B) 

OpenRect2 

2-side  open  Rectangle 

OpenRect2(B ,  right ,  front) 

LF(A,B ) 

OpenRect2(B ,  right. reverseQ,  front) 

RB(A,  B) 

OpenRect2(B,  right,  front.reverseQ) 

LB(A,B) 

OpenRect2(B,  right.reverseQ,  front.reverseQ) 

Table  10:  Open  shape  representation  for  direction  regions 


By  representing  each  direction  region  as  an  OpenShape,  we  process  direction  predicates  using  topological  relationship 
between  MBR  objects  and  OpenShapes.  This  is  the  basic  idea  behind  proposed  OSS  strategy.  If  the  direction  region  of  a 
predicate  is  an  open  line,  the  predicate  returns  TRUE  if  and  only  if  the  target  object  A  is  crossed  by  the  open  line. 


C  Topological  operations  for  OpenShapes 

C.l  The  crosses  Operation:  crosses(OpenLine  O,  Closed  shape  C) 

The  crosses  operation  applies  for  object  pair  between  an  open  line  O  and  a  closed  shape  C,  where  O  could  be  OpenLinel 
or  OpenLine2  and  C  could  be  points,  line  segments  and  polygons.  For  any  such  pair  of  O  and  C,  the  crosses  relation 
between  them  is  defined  as: 

O.crosses(C)  =  TRUE  <=>  O.dir  ©  Direct.ion(C  —  O.startPoint )  =  1;  (if  C  is  a  point) 

<=>  3  a  point  P  s.t.  P  £  interior(O)  PI  interior (C);(if  C  is  not  a  point) 

Figure  23  shows  some  examples  of  the  crosses  operations.  We  approximate  polygonal  closed  shape  by  rectangle  for 
simplicity,  however,  the  algorithm  will  work  for  convex  polygon  as  well.  Figure  23(a)  shows  an  OpenLinel  O  crosses 
a  point  C,  figure  23(b)  shows  O  crosses  a  line  segement  C,  and  Figure  23(c)  consists  of  the  five  possible  cases  that  an 
OpenLinel  crosses  a  polygon  C.  To  implement  the  crosses  operation,  we  use  vector  dot-product  and  the  isBetween 
operation  of  direction  objects.  For  the  case  of  OpenLinel  crosses  a  given  point,  such  as  in  figure  23(a),  the  OpenLinel  O 
crosses  the  given  point  C  if  and  only  if  the  vector-product  between  O.dir  and  the  direction  Direct.ion(C  —  O.startPoint ) 
equals  1.  For  the  case  of  OpenLinel(O)  crosses  a  line(C)  as  in  figure  23(b),  O.dir  should  be  between  the  two  directions 
constructed  by  the  two  endpoints  and  the  O.startPoint,  i.e.  dir  1  and  dir 2  in  the  figure.  The  crosses  relation  between 
an  OpenLinel  and  a  polygon  is  more  complicated  for  there  are  several  situations  possible  as  shown  in  figure  23(c).  We 
solve  them  by  enumerating  all  possible  situations  that  O.crosses(C)  will  be  TRUE.  Algorithm  6  describes  pseudocode  of 
OpenLinel::crosses.  The  topological  operations  contains  and  touches  for  closed  geometry  pairs  defined  by  OGIS  [12]  are 
used  in  the  algorithm  for  checking  if  O.startPoint  is  in  the  interior  or  on  the  boundary  of  the  polygon. 

Lemma  7  Algorithm  OpenLinel::crosses  is  complete  and  correct. 

Proof:  The  completeness  and  correctness  of  the  algorithm  OpenLinel ::crosses  for  Point  and  Line  are  proved  by  definition. 
In  the  following,  we  will  demonstrate  that  OpenLinel::crosses(Polygon)  is  complete  and  correct. 
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Algorithm  6  OpenLinel  Crosses  Points/Lines/Polygons 

Input:  closeShape  is  the  topologically  closed  object  that  needs  to  be  checked; 

the  current  OpenLinel  object,  which  has  attributes  ( dir,  Start-Point)-, 

Output:  TRUE  if  crossed,  FALSE  otherwise 

OpenLinel::crosses(Point  closeShape)  { 

dirl  =  Direction(closeShape  —  startPoint); 
if  (dir.deviate(dirl)) 
return  TRUE; 
return  FALSE; 

}; 

OpenLinel::crosses(Line  closeShape)  { 

dirl  =  Direction(closeShape.endpl  —  startPoint); 
dir2  =  Direction(closeShape.endp2  —  startPoint); 
if  (dir.isBetween(dirl,  dir2)) 
return  TRUE; 
return  FALSE; 

}; 

OpenLinel::crosses(  Polygon  closeShape){ 
for  each  side  £  sides  of  closeShape 
if  crosses  (side) 

return  TRUE; 

/*  The  following  deal  with  the  cases  O  does  not  cross  any  side  of  the  polygon  */ 
if  (closeShape. contains(startPoint))  /*  figure  23(c)  case  a:  startPoint  in  the  polygon  */ 
return  TRUE; 

if  (closeShape. touches(startPoint))  { 

if  startPoint  £  endpoints  of  closeShape  {  /*  figure  23(c)  case  d  */ 

for  each  ep  £  endpoints  of  closeShape 

if  crosses  (ep)  &&  !adjacent(startPoint,  ep) 
return  TRUE; 

}  else  {  /*  figure  23(c)  case  e:  startPoint  is  on  one  side  of  the  polygon  */ 

for  each  ep  £  endpoints  of  closeShape 

if  crosses  (ep)  &&  ep  ^endpoints  of  the  side  that  crosses  startPoint 
return  TRUE;  } 

return  FALSE; 

} 

/*  figure  23(c)  case  b  and  c  :  startPoint  is  outside  of  the  polygon  */ 
for  each  ep  £  endpoints  of  closeShape  { 
if  crosses  (ep)  { 

for  each  ep2  £  endpoints  of  closeShape  -{ep} 
if  (Iadjacent(ep,ep2)  &&  crosses(ep2)) 

return  TRUE;  /*23(c)  case  d:  O  crosses  non-adjacent  endpoints.*/ 

break;  } 
return  FALSE; 

}; 
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startPoint 
(a)  C  is  a  point 


endp2 


startPoint 

(b)C  is  a  line  segment 


endpl 


endp4 


P  /  endp2  endpl 

endp2 

Air/ 

dir/ 

endp4 

startP 

Hint  endp4  / 

endp3  / 

endp3  r 

0 

endp2 

endp3 


startPoint 
case  b 


endpl 


endp4 


/O 


’  endp2 


endpl 
endp3  endp4 


/  0 
’  endp2 
1  endp3 


(c)  C  is  a  polygon 


Figure  23:  OpenLines  crosses  Point/Line/Rectangle 


•  Completeness: 

For  an  OpenLinel(O)  and  a  Polygon(C),  there  are  two  possibilities: 

—  O  crosses  at  least  one  of  the  sides  of  the  polygon(figure  23(c)  case  b)  =>  O.crosses(C)  is  TRUE; 

—  O  doesn’t  cross  any  side  of  C.  The  algorithm  solves  this  possibility  by  considering  the  location  of  the  startPoint. 

1.  O. startPoint  is  within  the  polygon(figure  23(c)  case  a)  =>  O.crosses(C)  is  TRUE  ; 

2.  O. startPoint  is  outside  C,  O.crosses(C)  iff  O  crosses  two  non-adjacent  endpoints  of  C(figure  23(c)  case 

c)  ; 

3.  O. startPoint  is  on  the  boundary  of  C: 

Case  c:  O. startPoint  is  an  endpoint  of  C,  and  O  crosses  an  endpoint  ep  which  is  not  adjacent  to 
O. startPoint  =>  O.crosses(C)  is  TRUE 

case  d:  O. startPoint  falls  on  side  s  of  C,  O.crosses(C)  is  TRUE  iff  O  crosses  endpoint  ep  of  C 
and  ep  ^  endpoints  of  s. 

For  any  other  situation  that  is  not  described  above,  OpenLinel  does  not  cross  the  polygon.  Since  the  algorithm 
crosses  checked  all  the  above  situations,  the  algorithm  will  find  all  the  crosses  relation  between  an  OpenLinel  and 
a  polygon.  Therefore,  the  algorithm  is  complete. 

•  Correctness: 

The  algorithm  returns  TRUE  if  and  only  if  one  of  the  situation  is  satisfied,  in  which  case,  the  OpenLinel  crosses  the 
polygon.  The  algorithm  only  returns  TRUE  when  the  operation  crosses  hold,  therefore,  the  algorithm  is  correct.  ■ 

The  crosses  operation  between  an  OpenLine 2(two-end  openline)  opline2  and  a  closed  shape  can  be  implemented  by 
converting  the  opline2  to  two  OpeLine Is:  oplinela  and  oplinelb.  The  startPoint  of  each  OpenLinel  is  the  interPoint 
of  opline2,  and  the  dir  of  each  OpenLinel  is  opline2.dir  and  opline2.dir.reverse()  respectively.  The  opline2  crosses  the 
closed  shape  if  and  only  if  either  oplinela  or  oplinelb  crosses  the  object. 

C.2  The  contains  Operation  for  Open  Rectangles 

For  any  open  rectangle  O  and  closed  shape  C,  0.eontains(C)  returns  TRUE  if  and  only  if  C  is  wholly  contained  within  O. 
O  could  be  an  OpenRectl  or  an  OpenRect2,  and  C  could  be  a  point,  a  line  segment,  or  a  polygon.  The  formal  definition 
for  O.contains(C)  is  : 

O.contains(C)  =  TRUE  (OflC  =  C)  and  ( interior  (O )  fl  int.erior(C)  yf  0) 

Figure  24  shows  some  examples  of  the  contains  operations.  Figure  24(a)  are  exmples  that  satisfy  contains  relationship, 
where  figure  24(b)  are  examples  that  C  is  on  the  boundary  of  O,  but  not  contained  in  O. 

Since  we  are  only  interested  in  the  operations  that  are  used  for  directional  queries,  we  restrict  our  discussion  in  the 
cases  where  O  is  an  OpenRectl  or  OpenRect2,  and  C  is  a  point  or  a  polygon. 

The  contains  Operation  for  OpenRectl 

OpenRectl  is  an  one-side  open  rectangle.  Figure  25  shows  the  examples  that  an  OpenRectl  contains  a  point/polygon.  The 
implementation  of  the  contains  operation  can  be  accomplished  by  using  isBet.ween  operator  and  the  crosses  operation. 
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(a)  Examples  that  satisfy  O.contains(C) 


(a)  Examples  that  does  not  satisfy  O.contains(C) 


Figure  24:  Examples  of  contains  relationship 


dirl.isBetween(dir,dir2)  && 
dir3.isBetween(dir,  dir2.reverse()) 

(a)  C  is  a  point 


any  endpoint  is  either  on  the  boundary  or  contained  in  the  oprectl 
(b)  C  is  a  polygon 


Figure  25:  OpenRectl  contains  point/line/polygon 


In  order  to  check  if  a  point  is  contained  in  OpenRectl(figure  25a),  two  direction  objects  are  constructed  by  substracting 
the  point  C  from  each  endpoints  of  the  OpenRectl,  and  isBetween  operations  is  applied. 

For  any  convex  polygon  C,  if  there  does  not  exist  any  endpoint  that  is  outside  the  OpenRectl,  i,e.,  every  endpoint  of 
C  is  contained  in  the  OpecRectl  or  located  on  the  boundary  of  the  OpenRectl,  then  C  is  contained  in  the  OpenRectl. 
Algorithm  7  describes  the  operation  in  pseudocode. 

The  contains  Operation  for  OpenRect2 

OpenRect2  is  a  two-side  open  rectangle,  which  is  described  by  one  endpoint  and  two  directions.  Figure  26  shows  several 
situations  that  an  OpenRect2  contains  a  Point  or  a  Polygon.  Similar  to  the  case  of  OpenRectl,  the  isBetween  operation  of 


-V 

O 


Any  endpoint  is  either  contained  in  oprect2  or  on  the  boundary 


(a)  C  is  a  point 


(b)  C  is  a  polygon 


Figure  26:  OpenRect2  contains  point/line/polygon 

the  direction  objects  is  used  to  implement  the  contains  operation  between  an  OpenRect2  and  a  point.  A  convex  polygon 
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Algorithm  7  OpenRectl  contains  Point/Polygon 

Input:  closeShape  is  the  topologically  closed  object  that  needs  to  be  checked; 

the  current  OpenRectl  object,  which  has  attributes  (endpl,  endp2,  dir); 
Output:  TRUE  if  contain,  FALSE  otherwise 

OpenRectl::contains(Point  closeShape)  { 

dirl  =  Direction(closeShape  —  endpl); 
dir2  =  Direction(endp2  —  endpl); 
if  (dir.isBetween(dirl,  dir2))  { 

dir3  =  Direction(closeShape  —  endp2); 
if  dir3.isBetween(dir,dir2.reverse()) 
return  TRUE; 

} 

return  FALSE; 

}; 

Open  Recti  ::contains(  Polygon  closeShape){ 
oplinela  =  OpenLinel(endpl,  dir); 
oplinelb  =  OpenLinel(endp2,  dir); 
aLine  =  Line(endpl,  endp2); 
for  ep  €  endpoints  of  closeShape 

if  !(endpl  ==  ep  ||  endp2  ==  ep  ||  contains(ep)  || 

oplinela. crosses(ep)  ||  oplinelb. crosses(ep)  ||  aLine. crosses(ep)) 
return  FALSE; 
return  TRUE; 

}; 


is  contained  in  the  OpenRect2  if  every  endpoints  of  the  polygon  is  either  contained  in  the  OpenRect2  or  on  the  boundary. 
The  pseudocode  is  described  in  algorithm  8. 

Completeness  and  Correctness  of  the  algorithms 

Lemma  8  Algorithm  OpenRectl::contains  and  OpenRect2::contains  are  complete  and  correct. 

Proof: 

•  Completeness: 

For  object  pair  of  OpenRectl(O)  and  Point(C),  there  is  only  one  case  that  O.contains(C)  is  true,  that  is  C  is 
in  the  interior  of  O.  The  completeness  of  the  algorithm  is  clear  by  definition.  For  the  case  of  checking  Open¬ 
Rectl. contains(Polygon),  the  algorithm  7  excludes  only  the  cases  that  there  exist  some  endpoints  of  the  polygon 
outside  the  OpenRectl,  when  the  polygon  is  absolutely  not  wholly  contained  in  OpenRectl.  Therefore,  the  algo¬ 
rithm  will  find  all  cases  when  the  relationship  contains  is  satisfied.  The  clgorithm  find  all  possible  contain  relations, 
so  is  complete. 

•  Correctness: 

The  algorithm  OpenRectl. contains(Point)  returns  TRUE  if  and  only  if  the  point  is  contained  in  the  interior  of  the 
OpenRectl.  For  the  object  pair  of  an  OpenRectl  and  a  convex  polygon,  the  algorithm  returns  TRUE  if  and  only  if 
every  endpoint  of  the  polygon  is  either  contained  or  on  the  boundary  of  the  OpenRectl,  in  which  case,  there  does 
not  exist  any  point  in  the  interior  of  the  polygon  which  is  not  contained  in  the  OpenRect2.  therefore,  the  algorithm 
will  return  TRUE  only  when  polygon  is  wholly  contained  in  OpenRectl. 

The  argument  of  the  completeness  and  correctness  for  algorithm  8  is  similar.  ■ 
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Algorithm  8  0penRect2  contains  Point /Line /Polygon 

Input:  closeShape  is  a  topologically  closed  object; 

the  current  0penRect2  object,  which  has  attributes  ( startPoint, dirl,dir2)\ 

Output:  TRUE  if  contain,  FALSE  otherwise 

OpenRect2::contains(Point  closeShape)  { 

dir  =  Direction(closeShape  —  startPoint); 
if  (dir.isBetween(dirl,  dir2)) 
return  TRUE; 
return  FALSE; 

}; 

Open Rect2::contains( Polygon  closeShape){ 
oplinela  =  OpenLinel(startPoint,  dirl); 
oplinelb  =  OpenLinel(startPoint,  dir2); 
for  ep  €  endpoints  of  closeShape 

if  ! (ep  ==  startPoint  ||  contains(ep)  ||  oplinela. crosses(ep)  ||  oplinelb. crosses(ep)) 
return  FALSE; 
return  TRUE; 

}; 
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